Release 10.1A: OpenEdge Development:
Messaging and ESB

Reply mechanisms

This section applies to both the Pub/Sub and the PTP domains.

Java-JMS provides no built-in mechanism for replies. It is the responsibility of the application to:

Designate a Destination object (typically a temporary destination) for replies.
Send this Destination object to the receiver (typically through the ReplyTo field in the message header, a set of fields containing values to identify and route the message).

The receiver must extract the reply destination from the message and follow the normal publish (or send) steps to reply.

The 4GL-JMS API simplifies this process, both for the sender needing a reply and for the receiver needing to reply:

Sender — The 4GL-JMS API requestReply procedure can publish messages in the same way as the publish procedure, or send messages to a queue in the same way as the sendToQueue procedure. In addition, a Message Consumer object for replies is passed to the requestReply procedure as an input parameter. The 4GL-JMS implementation automatically routes all the replies to that Message Consumer object. See the "Request/Reply" section for additional information.
Receiver — To reply, the message receiver returns a reply message handle as an output parameter in the message-handling routine. The application can call the setReplyPersistency procedure in the Message Consumer object to automatically delete replies after sending them.

An application can also publish a reply message or send it to a queue by first calling the getReplyToDestinationType function to extract the name of the reply destination, and then calling the publish procedure or sendToQueue procedure directly.

Note: If the ReplyTo destination is a temporary destination, an application must send a reply before deleting the original message. (See the Java Message Service specification and SonicMQ Programming Guide for information on temporary destinations.) Deleting the original message tells the 4GL-JMS implementation that the ReplyTo temporary destination will no longer be used.

By default, the type of the ReplyTo destination matches the type of the origin of the message:

If the message was created by a Pub/Sub Session object, the value of the ReplyTo field is considered a topic name.
If the message was created by a PTP Session object, the value of the ReplyTo field is considered a queue name.

However, it is legal to designate a queue for replying to a published message, or a topic for replying to messages received from a queue. To accommodate this, the 4GL-JMS API supports the setReplyToDestinationType procedure and the getReplyToDestinationType function, both of which support the CHARACTER values topic and queue.

The setReplyToDestinationType procedure must be called if the 4GL application calls the setJMSReplyTo procedure and sets a destination from a domain other than that of the session. The getReplyToDestinationType function must be called when the 4GL application receives a message and wants to reply to it, but is not certain about the ReplyTo domain.

Using a second session for replying

In some cases the 4GL application might need to reply through a different session from the one that receives the original message. For example, the publisher of the message might want to designate a queue, rather than a topic, for receiving the replies. In such a case, the publisher sets the JMSReplyTo header field to the name of the queue and then publishes the message. The receiver receives the message through a Pub/Sub session, extracts the queue from the JMSReplyTo header field, and uses a PTP Session object to send the reply to that queue. The original publisher then uses a Pub/Sub Session object to receive the reply.

The 4GL-JMS API supports such transactions with these limitations:

The JMSReplyTo header field cannot be set with the name of a temporary destination that came from a session other than the one used to send the message.
If the 4GL application sets JMSReplyTo with a destination domain different from that of the session that will be used to send the message, it must use the Java Naming and Directory Interface (JNDI) (or other administered object storage) name of that object. (See OpenEdge Application Server: Administration .)
An automatic reply (through the reply output parameter of the message-handling routine) does not work if the domain specified in the JMSReplyTo header field differs from that of the session. The application must send the reply explicitly through a second session.